System and method for network access vending

ABSTRACT

A system, method and apparatus for vending network access by determining access pricing or tariffs for one or more of a plurality of network access regions using one or more of an eNB cell congestion level, an eNB congestion level, a quality of service level, an access technology, a level of activity by a target subscriber and the like. The access pricing is offered to potential access purchasers along with optional metadata indicative of, illustratively, user equipment and network parameters associated with the cell or eNB. The pricing may be offered via an API to allow automatic purchase decisions by access purchasers.

FIELD OF THE INVENTION

The invention relates generally to managing network resources and, morespecifically but not exclusively, adapting resource pricing according todynamic conditions.

BACKGROUND

Wireless access providers are experiencing explosive growth in datatraffic due to smart phones, tablets, shared networking devices as wellas new applications and services. These devices typically receiveservices from internet based applications and services rather than fromproviders' own domains.

The present provider model is one of selling access or capacity tosubscribers, with plans that typically impose a monthly usage allowance.For a fixed fee, subscribers can receive content independent of thenetwork conditions. In response, users of network capacity are sensitiveto their total consumption but not sensitive to network loading levelssuch that bandwidth consuming applications are used independent of theimpact on the network.

To satisfy user needs, access providers must build out their networks tohandle large peaks in subscriber traffic. This situation is particularlyproblematic for the air interface, where the limited volume of trafficdoes not provide the same degree of statistical multiplexing as in thecore network. Air interface traffic peaks typically occur only duringlimited time periods and on a limited number of cells. This leaves ahuge amount of network data carrying capacity idle during non-peakperiods and therefore not monetized.

BRIEF SUMMARY

Various deficiencies of the prior art are addressed by the presentinvention of a method, system and apparatus to provide a market in whichnetwork access itself (rather than just bandwidth consumption) isoffered as a commodity for purchase by third parties at a price definedby contemporaneous network conditions, service level or tier,co-sponsorship or advertising subsidy and the like.

Various embodiments for vending network access contemplate determiningaccess pricing or tariffs for one or more of a plurality of networkaccess regions using one or more of an eNB cell congestion level, an eNBcongestion level, a quality of service level, an access technology(e.g., 2G vs. 3G vs. 4G), a level of activity by a target subscriber andthe like. The pricing is offered to potential access purchasers alongwith optional metadata indicative of, illustratively, user equipment andnetwork parameters associated with the cell or eNB. The pricing may beoffered via an API to allow automatic purchase decisions by accesspurchasers, such as when pricing conditions are appropriate.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present invention can be readily understood byconsidering the following detailed description in conjunction with theaccompanying drawings, in which:

FIG. 1 depicts an exemplary communication system benefiting from anembodiment;

FIG. 2 depicts an exemplary management system suitable for use incommunication system of FIG. 1;

FIGS. 3-4 depict flow diagram of a methods according to variousembodiments; and

FIG. 5 depicts a high-level block diagram graphically representing anAccess Market Place (AMP);

FIG. 6 graphically depicts exemplary application content providerpolicies for two different application content providers; and

FIG. 7 depicts a high-level block diagram of a general purpose computersuitable for use in performing the functions described herein withrespect to the various embodiments.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION OF THE INVENTION

The invention will be described within the context of a method, systemand apparatus to provide a market in which network access itself (notjust bandwidth consumption) is offered as a commodity for purchase bythird parties at a price defined by contemporaneous network conditions,service level or tier, co-sponsorship or advertising subsidy and thelike.

Although primarily depicted and described herein within the context ofproviding, illustratively, an access marketplace to sell access to a 4GLTE wireless network, it will be appreciated that the access marketplaceis readily adapted to vending access to other wireless networks such as3GPP, 3GPP2, 4G, LTE, UMTS, EV-DO, 802.11, WiMAX and the like, as wellas non-wireless networks or combinations of wireless and non-wirelessnetworks. Thus, the various network elements, links and other functionalentities described herein with respect to an LTE network may be broadlyconstrued to also describe corresponding network elements, links andother functional entities associated with various other types ofwireless and non-wireless networks.

Generally speaking, the various embodiments discussed herein provide amechanism for establishing an access network market to sell wirelessnetwork access (or other network access) to third parties accesspurchasers (APs) such as application service providers, applicationcontent providers, machine to machine (M2M) service providers and thelike. Using the various embodiments described herein, network accessproviders are able to monetize what is arguably the most valuablecommodity they possess; namely, connectivity to mobile devices byvarious application services and service providers, and to do so in amanner that applies the principle of supply and demand to a limitedresource, network capacity.

FIG. 1 depicts an exemplary wireless communication system includingmanagement and backup/protection functions according to an embodiment.Specifically, FIG. 1 depicts an exemplary wireless communication system100 that includes a plurality of User Devices (UDs) or User Equipment(UE) 102, a Long Term Evolution (LTE) network 110, IP networks 130, anetwork management system (MS) 140 and a plurality of Access Purchasers(AP) 150.

The LTE network 110 supports communications between the UDs 102 and IPnetworks 130, which in turn supports communications to the APs 150.

The MS 140 is configured for supporting various management functions forLTE network 110. The configuration and operation of LTE networks will beunderstood by one skilled in the art.

The exemplary UDs 102 are wireless user devices capable of accessing awireless network, such as LTE network 110. The UDs 102 are capable ofsupporting control signaling in support of the bearer session(s). TheUDs 102 may be mobile phones, personal digital assistants (PDAs),computers, tablets devices or any other wireless user device.

The exemplary LTE network 110 includes, illustratively, a plurality ofeNodeBs 111 ₁ through 111 _(N) (collectively, eNodeBs 111), one or moreServing Gateways (SGWs) 112 ₁ and 112 ₂ (collectively, SGWs 112), aPacket Data Network (PDN) Gateway (PGW) 113, a Mobility ManagementEntity (MME) 114, a Policy and Charging Rules Function (PCRF) 115 andvarious other network elements (not shown) supporting control planeand/or data plane operations. The eNodeBs 111 provide a radio accessinterface for UDs 102. The SGWs 112, PGW 113, MME 114, and PCRF 115, aswell as other components which have been omitted for purposes ofclarity, cooperate to provide an Evolved Packet Core (EPC) networksupporting end-to-end service delivery using IP.

The eNodeBs 111 support communications for UDs 102. As depicted in FIG.1, each eNodeB 111 supports a respective plurality of UDs 102. Thecommunication between the eNodeBs 111 and the UDs 102 is supported usingLTE-Uu interfaces associated with each of the UDs 102.

The SGWs 112 support communications for eNodeBs 111 using,illustratively, respective S1-u interfaces between the SGWs 112 and theeNodeBs 111. The S1-u interfaces support, illustratively, per-beareruser plane tunneling and inter-eNodeB path switching during handover.

As depicted in FIG. 1, either or both of SGW 112 ₁ and SGW 112 ₂supports communications for the various eNodeBs 111. It will beappreciated that a single SGW 112 may be used to provide this support,or that more than two SGWs 112 may be used.

The PGW 113 supports communications for the SGWs 112 using,illustratively, respective S5/S8 interfaces between PGW 113 and SGWs112. The S5 interfaces provide functions such as user plane tunnelingand tunnel management for communications between PGW 113 and SGWs 112,SGW relocation due to UD mobility, and the like. The S8 interfaces,which may be Public Land Mobile Network (PLMN) variants of the S5interfaces, provide inter-PLMN interfaces providing user and controlplane connectivity between the SGW in the Visitor PLMN (VPLMN) and thePGW in the Home PLMN (HPLMN). The PGW 113 facilitates communicationsbetween LTE network 110 and IP networks 130 via an SGi interface.

The MME 114 provide mobility management functions in support of mobilityof UDs 102. The MME 114 supports the eNodeBs 111 using, illustratively,respective S1-MME interfaces which provide control plane protocols forcommunication between the MME 114 and the eNodeBs 111.

The PCRF 115 provides dynamic management capabilities by which theservice provider may manage rules related to providing Quality ofService (QoS) via LTE network 110 and rules related to charging forservices provided via LTE network 110.

As depicted and described herein with respect to FIG. 1, elements of LTEnetwork 110 communicate via interfaces between the elements. The LTEnetwork 110 includes an Evolved Packet System/Solution (EPS). In oneembodiment, the EPS includes EPS nodes (e.g., eNodeBs 111, SGWs 112, PGW113, MME 114, and PCRF 115) and EPS-related interconnectivity (e.g., theS* interfaces, the G* interfaces, and the like). The EPS-relatedinterfaces may be referred to herein as EPS-related paths.

The IP networks 130 include one or more packet data networks via whichUDs 102 may access content, services, and the like.

The MS 140 provides management functions for managing the LTE network110. The MS 140 may communicate with LTE network 110 in any suitablemanner. In one embodiment, for example, MS 140 may communicate with LTEnetwork 110 via a communication path 141 which does not traverse IPnetworks 130. In one embodiment, for example, MS 140 may communicatewith LTE network 110 via a communication path 142 which is supported byIP networks 130. The communication paths 141 and 142 may be implementedusing any suitable communications capabilities. The MS 140 may beimplemented as a general purpose computing device or specific purposecomputing device, such as described below with respect to FIG. 2 or 5.

The Access Purchasers (AP) 150 comprise third-party entities such asAccess Content Providers (ACPs), Application Service Providers (ASPs),machine to machine (M2M) service providers or monitoring entities andthe like. These third-party entities may have a separate contractualrelationship with subscribers/users of the LTE network 110, where thesubscribers/users access the LTE network 110 via respective UD/UE 102.

In some cases, access purchasers entities may choose to pay for some orall of the cost of providing content, application services, M2M servicesand the like to subscriber UDs 102. The various embodiments are adaptedfor use within a number of different business scenarios/applications,which will be described below in more detail.

FIG. 2 depicts an exemplary management system suitable for use in thecommunications system of FIG. 1. As depicted in FIG. 2, MS 140 includesone or more processor(s) 210, a memory 220, a network interface 230N,and a user interface 230U. The processor(s) 210 is depicted as beingcoupled to each of the memory 220, the network interface 230N, and theuser interface 230U, though other computer architectures are alsosuitable for use within the context of the management system 140.

The processor(s) 210 is adapted to cooperate with the memory 220, thenetwork interface 230N, the user interface 230U, and the supportcircuits 240 to provide various management functions for LTE network 110as well as for the various access market embodiments discussed herein.

The memory 220, generally speaking, stores programs, data, tools and thelike that are adapted for use in providing various management functionsfor LTE network 110 as well as for the various access market embodimentsdiscussed herein.

The memory 220 illustratively includes a network management engine (NME)221, a network management database (NMD) 222, a market pricing engine(MPE) 225, a market transaction engine (MTE) to 26 and a market database227. In one embodiment, the NME 221, MPE 225 and MTE 226 are implementedusing software instructions which may be executed by processor (e.g.,processor(s) 210) for performing the various management functionsdepicted and described herein.

The NMD 222 and MD 227 each store data which may be generated by andused by various ones and/or combinations of the engines and tools ofmemory 220. The NMD 222 and MD 227 may be combined into a singledatabase or implemented as respective databases, memory structuresand/or portions thereof. Either of the combined or respective databasesmay be implemented as single databases or multiple databases accordingto various arrangements as known to those skilled in the art.

Although depicted and described with respect to an embodiment in whicheach of the engines and databases are stored within memory 120, it willbe appreciated by those skilled in the art that the engines anddatabases may be stored in one or more other storage devices internal toMS 140 and/or external to MS 140. The engines and databases may bedistributed across any suitable numbers and/or types of storage devicesinternal and/or external to MS 140. The memory 220, including each ofthe engines and/or databases of memory 220, is described in additionaldetail herein below.

The network interface 230N is adapted to facilitate communications withLTE network 110 and IP network(s) 130. For example, network interface230N is adapted to interact with various management entities within theLTE network 110 to perform various network management functions,including receiving information adapted for use in determining thetopology, operating conditions, utilization levels, congestion levels,alarm conditions, status conditions and so on associated with theoperations of the LTE network 110. The interface 110 is also used tosignal pricing changes to the LTE network so they may be applied tocontent sent by APs. For example in one embodiment the network interface230N may be used to signal to the PCRF 115 that a new charging ruleshould be applied for packet flows from APs. Similarly, networkinterface 230N is adapted to interact with access purchasers 150 via,illustratively, one or more IP networks 130 implement various accessmarket functions such as described herein.

The user interface 230U is adapted to facilitate communications with oneor more user workstations (illustratively, user workstation 250), forenabling one or more network operations center (NOC) or other managementusers to perform management functions associated and/or access marketfunctions. The communications include communications to user workstation250 (e.g., for presenting imagery generated by MS 140) andcommunications from user workstation 250 (e.g., for receiving userinteractions with information presented via user workstation 250).Although primarily depicted and described as a direct connection betweenMS 140 and user workstation 250, it will be appreciated that theconnection between MS 140 and user workstation 250 may be provided usingany suitable underlying communication capabilities, such that userworkstation 250 may be located proximate to MS 140 (e.g., such as whereboth MS 140 and user workstation 250 are located within a NetworkOperations Center (NOC)) or remote from MS 140 (e.g., such as wherecommunications between MS 140 and user workstation 250 may betransported over long distances).

Although primarily depicted and described herein with respect to oneuser workstation, it will be appreciated that MS 140 may communicatewith any suitable number of user workstations, such that any number ofusers may perform management functions for LTE network 110 (e.g., suchas where a team of technicians at a NOC access MS 140 via respectiveuser workstations for performing various management functions for LTEnetwork 110). Although primarily depicted and described with respect touser workstations, it will be appreciated that user interface 230U maybe adapted to support communications with any other devices suitable foruse in performing the various functions discussed herein.

As described herein, memory 220 includes the NME 221, NMD 222, MPE 225,MTE 226 and MD 227, which cooperate to provide the various functionsdepicted and described herein. Although primarily depicted and describedherein with respect to specific functions being performed by and/orusing specific ones of the engines and/or databases of memory 220, itwill be appreciated that any of the management functions depicted anddescribed herein may be performed by and/or using any one or more of theengines and/or databases of memory 220.

Network Management Engine

The network management engine (NME) 221 is generally adapted forproviding various network management functions associated with,illustratively, LTE network 110. The NME performs various networkmanagement functions as known to those skilled in the art. Suchfunctions include, illustratively, discovery of network elements andtheir interconnections, provisioning paths to the network, andmonitoring various performance parameters associated with networkelements, links and/or portions thereof.

Thus, in addition to various other functions, the network managementengine 221 retrieves configuration information, status/operatinginformation and connection information regarding the elements,sub-elements and links forming the LTE network 110. Much of thisinformation is dynamic and the retrieval of this information by thenetwork management engine 221 is ongoing. For example, the underlyingelements, sub-elements and links within the LTE network may change overtime due to local network adaptations, rerouting, failures,degradations, scheduled maintenance and the like. In general, thenetwork management engine 221 is adapted to provide management andmonitoring of the various elements, sub-elements and links forming theLTE network 110.

Configuration information comprises information identifying a networkelement, the function and/or configuration of the network element, thefunction and/or configuration of the sub-elements forming a networkelement and so on. Configuration information illustratively includes,but is not limited to, information identifying the type of networkelement, protocols supported by the network element, services supportedby the network element and so on. Configuration informationillustratively includes information attending to the varioussub-elements within the network element, such as the input ports,switches, buffers, and output ports and so on associated with thesub-elements forming a network element.

Status/operating information comprises status/operating informationassociated with the operating state of the network element and/or thesub-elements forming a network element. Status/operating informationillustratively includes, but is not limited to, information providingoperating status/alarm indicators, including information pertaining tometrics such as packet count, utilization level, component pass/failindication, bit error rate (BER) and the like. Status information may beobtained directly from network elements, from network elements viaindependent probes, or from information obtained from the UE 102.

Connection information comprises information useful in ascertaining orinferring the connections between network elements and/or sub-elements,such as the source of data received from the network element or itssub-elements, the destination of data transmitted by the network elementor its sub-elements and so on. Connection information illustrativelyincludes, but is not limited to, source address information associatedwith received packets, destination address information associated withtransmitted packets, protocol information associated with packet flows,service information associated with packet flows, deep packet inspectionresults data and the like.

The network management engine 221 stores configuration information,status/operating information, connection information and otherinformation useful in performing the various management functions withinthe network management database (NMD) 222.

Market Pricing Engine

The market pricing engine (MPE) 225 performs various functionsassociated with determining prices to be paid by third parties such asapplication content providers, application service providers, machine tomachine (M2M) service providers and the like to access one or moreportions of the LTE network 110. Various factors enter into the pricingdetermination mechanism, including one or more of local networkcongestion levels, intermediate network congestion levels, requestedservice levels (gold, silver and bronze tiers, for example), mostfavored buyer status, pre-existing business arrangements, pre-existingservice level agreements, advertising offset opportunities and so on.Generally speaking, the cost of access via the LTE network 110 increasesas the network becomes more utilized and decreases as the networkbecomes less utilized, as will be discussed in more detail below.

The market pricing engine 225 stores current and, optionally, historicalmarket pricing information within the market database (MD) 227. Themarket pricing engine 225 interfaces to the LTE network and ensures thatcurrent pricing levels are applied to data sent to/from the APs.

Market Transaction Engine

The market transaction engine (MTE) 225 performs various functionsassociated with access purchases and other transactions with the variousaccess purchasers (APs), such as access content providers, applicationservice providers, machine to machine service/monitoring providers orany other entity interested in purchasing network access for itself orits customers.

The market transaction engine 225 interacts with access purchasers 150to advertise/offer network access at various regions, various prices andso on as determined by the market pricing engine 225. The variousregions may comprise individual mobile sites such as a base station oreNodeB, specifically defined geographic regions such as a city or otherdelineated region.

Access Market Embodiments

It will be appreciated by those skilled in the art that the functions ofthe market pricing engine 225, market transaction engine 226 and/ormarket database 227 may be implemented as part of the management system140 as depicted herein, as part of a dedicated computing system/serverlocated proximate or remote from the management system 140, or as partof a standalone access market brokering system.

Per Cell Market Example

Various embodiments will now be discussed within the context of vendingaccess to wireless network users associated with a particular region;namely, a single cellular region such as associated with one basestation or eNodeB.

FIG. 3 depicts a flow diagram of a method according to one embodiment.Specifically, FIG. 3 depicts a method 300 suitable for use by,illustratively, the market pricing engine 225 discussed above withrespect to FIG. 2.

At step 310, per-cell or per-eNB network congestion information isobtained. Referring to box 315, this information may be obtained vianetwork monitoring tools, the network management system, user equipmentor devices and so on. Moreover, the network congestion information maycomprise current network conditions or historic network conditions.

For example, various network monitoring tools may be access/core networkvendor agnostic, monitoring messages and transport on standardizedinterfaces, or the tools may be network vendor proprietary, interfacingto network elements or the OA&M systems. Per-cell or per-eNB networkcongestion information may include data associated with any of theair-interface, backhaul and core network. Network congestion informationmay also include indications of network element status, such as networknode processor occupancy, memory availability and so on the may beaffected by network loading/congestion.

At optional step 320, other information useful in determining networkaccess value is obtained. Referring to box 325, such other informationmay include connectivity technology used (e.g., LTE, UMTS, WiFi and thelike), user equipment status (e.g., processor occupancy, memoryavailability and the like), quality of access level (e.g. gold, silver,runs and the like), quality of experience (QoE) level, request or needfor guaranteed bandwidth, minimum bandwidth, best effort bandwidth andother information/factors.

At step 330, per-cell or per-eNB network access pricing is determinedusing obtained network congestion information and/or other informationas described herein. Generally speaking, while prices may be formulatedbased upon many factors such as multiple access grades and the like,congestion levels at the cell and/or eNodeB are highly determinative.Prices will tend to rise and fall in relation to congestion levels,though this relationship is not necessarily linear. Generally speaking,a network region to be associated with an access price or tariff maycomprise a region serviced by one or more of an eNodeB, an eNodeB cell,a NodeB, a Node B cell, a base transceiver station (BTS), a BTS cell andso on.

At step 340, the determined per-cell or per-eNB access pricing isoffered or advertised. Optionally, metadata associated with the networkand/or with user equipment is included with the advertise network accessprice. For example, metadata identifying a user device and a cell withinwhich the device is located will enable an access purchaser to correctlyidentify the appropriate cell or Gateway servicing the user device, suchas to enable content streaming and the like.

Referring to box 345, the offered per-seller per-eNB network access maybe advertised via a network access broker, and electronic datainterchange, an application programming interface (API) for anapplication service, via an API for the content distribution service,via an API for an M2M service, the via a secure application API, via atrusted agent, via a secure certificate or by some other mechanism. Forexample, in one embodiment, pricing as well as other meta-dataindicating UE status and access network state are offered via RESTfulAPIs interfaced to applications. The APIs pass through, illustratively,a secure interface such as a Web Services Gateway, illustratively theAlcatel-Lucent Open API Platform—OAP).

Generally speaking, the method 300 of FIG. 3 is adapted to determinepricing associated with per-cell, per-eNB or some other network accesssegment, such as a specific region, carrier, service class and the like.The determined pricing is offered to access purchasers via one or moremechanisms, some of which optionally include metadata useful in enablingaccess purchasers to identify the appropriate network access to bepurchased for specific subscribers or users.

Thus, in various embodiments of a method for vending network access,access pricing or tariffs for one or more of a plurality of networkaccess regions is determined using one or more of an eNB cell congestionlevel, an eNB congestion level, a quality of service level, an accesstechnology (e.g., 2G vs. 3G vs. 4G), a level of activity by a targetsubscriber and the like.

FIG. 4 depicts a flow diagram of a method according to one embodiment.Specifically, FIG. 4 depicts a method 400 suitable for use by,illustratively, the market transaction engine 226 discussed above withrespect to FIG. 2. This embodiment contemplates servicing individualpurchase requests via the Management System 140. Other embodimentscontemplate servicing individual purchase requests via a global chargingpolicy applied to all content sent to or received from an AP.

At step 410, a network access purchase request is received from anaccess purchaser (AP). Referring to box 415, the access purchase requestmay be received via a marketplace API such as discussed above withrespect to step 340 of box 345 or via some other mechanism.

At step 420, the type of application associated with the network accesspurchase request is identified such that appropriate networkprovisioning, charging and general fulfillment requirements may besatisfied. Referring to box 425, types of applications include sponsoredcontent applications, machine to machine (M2M) applications,applications where network access is a supporting attribute and otherapplications. A sponsored content application may comprise anapplication in which the application provider sponsors content forsubscribers. The sponsored content may be an application providedpromotion, selected by the subscriber as part of an offering by theapplication content provider, or linked to a service plan. A M2Mapplication may comprise a threshold-triggered decision by a machine orother processing element that network access pricing is appropriate fora relevant data transfer. An application where network access is asupporting attribute may comprise a device- or appliance-dependentapplication by which purchased content such as books or streamingcontent is delivered to the device or appliance by one or more networkswithout a subscriber incurring further access charges for this delivery,or having the content count against a monthly usage allowance.

At step 430, interaction with the network management engine 221 isprovided to fulfill the network access purchase request. For example,referring to box 435, in one 4G/LTE embodiment, the service purchaserequest and any service grade information is forwarded to the Policy andCharging Resource Function (PCRF) entity by the management system 140via the OAP. Generally speaking, the PCRF adapts policy and chargingbased network functions to ensure that the service level associated withthe access purchase request is satisfied and that the applicationinitiating the access purchase request is appropriately charged for thisnetwork access at the determined pricing.

For example, if a better-than-best-effort level of service has beenselected in the axis purchase request, in one embodiment the PCRF setsup a QoS bearer corresponding the grade of service selected using 3GPPstandardized mechanisms. The PCRF also establishes a charging rule forthe requested content and promulgates the information to the policyenforcement point (PGW in LTE). The LTE packet Gateway (PGW) countspackets associated with the application separately from other packetsbeing sent to the user. If the signature (e.g., a 5-tuple or othersignature) of the content is unknown or was not included within the axispurchase request, then the PGW may use DPI to detect the flow associatedwith the application that has purchased access. Generally speaking, thePGW operates to ensure that purchased application-related packets arenot attributed to the subscriber bandwidth allocation; rather, thesepackets are chargeable to the network access purchasing application orentity. It is noted that the charging system, which may be an online oroff-line charging system, rates the packet counts for 3rd partypurchased access separately from packet counts associated with othersubscriber activity.

Generally speaking, the method 400 of FIG. 4 is adapted to receivenetwork access purchase requests from applications and interact with thenetwork management engine and/or other network management components asnecessary to fulfill the axis purchase request and charge the requestingapplication or entity for this service.

The various embodiments described herein advantageously allowapplication service providers, content providers and others to purchaseaccess at a price that is correlated with network congestion levelsand/or other factors. When congestion levels are high, the price foraccess rises in the marketplace, discouraging consumption of networkresources in the marketplace. When network resources are idle, the pricefor access falls in the marketplace and applications may make purchasesfor delivery of their content at economical prices.

Various embodiments of the invention utilize RESTful APIs exposed by theoperator that 3rd party content providers may access. The APIs provideaccess price information (which may be denoted in dollars or othercurrency units per megabyte, gigabyte or other bandwidth quantity) andmetadata associated with the access being purchased. Various embodimentsinclude the option to offer multiple tiers of service (Gold, Silver,Bronze, Guaranteed Bit Rate and the like), which tiers of service may beoffered for purchased at different pricing levels. The variousembodiments also include a mechanism for the applications to purchaseaccess using REST APIs as described herein.

Various embodiments apply a current applicable charging rate for anycontent sent by, illustratively, pre-approved participants in themarketplace. No API need be exercised to make a purchase by the AP; theAP identifies a price advertised in the API and makes an implicitpurchase decision by sending content. For M2M devices, all packets sentto the device on a cell are charged at the prevailing advertised ratefor that cell. For regular subscriber devices, a traffic detectionfunction (DPI) could detect the sponsored content flow and triggercharging against the AP rather than the subscriber. Various embodimentsuse a third party access broker operating as intermediary between anaccess price determination and/or offering mechanism and potentialaccess purchasers.

M2M Embodiments and Applications

Machine to machine (M2M) applications comprise, illustratively,applications such as automatic inventory control of remote vendingmachines, numerous remote monitoring/sensor applications, automobilemaintenance/update applications, firmware update applications for mobiledevices and so on. These applications are typically flexible withrespect to scheduling the delivery of content, updates or other data toor from a remote device. As such, where network access pricing isrelated to network congestion or utilization levels, scheduling suchdelivery for low price/congestion time periods may be achieved. Inparticular, various embodiments of M2M data refresh/deliveryperiodically monitor network access pricing levels and opportunisticallyschedule data refresh/delivery in response to pricing levels droppingbelow a maximum threshold level. In this manner, M2M costs may becontrolled and possibly driven to levels sufficiently low to enableentire new classes of M2M systems or applications.

Within the context of various M2M solutions supported by the variousembodiments, wireless access is a component of a dedicated service. Thewireless access is preferentially purchased below threshold triggerlevels to opportunistically take advantage of drops in offered accesspricing. In this manner, M2M applications that have heretofore beenimpossible due to cost constraints may now be provided by M2Mapplication vendors.

Sponsored Content Embodiments and Applications

Sponsored content embodiments are where application or content serviceproviders pay some or all of the costs of delivering the application orcontent to subscribers via a network.

In one embodiment, special-purpose devices such as electronic readersare used to deliver content to subscribers. For example, an electronicbook vendor may sell dedicated subscriber devices (e-readers) that allowsubscribers to sign-up for the book delivery service where theelectronic book vendor pays an access provider such as a wirelessnetwork owner to deliver content to the subscribers. Basic or minimumcontent only may be provided while access costs are high, while richcontent may require delivery when access costs are much lower.

In one embodiment, a general purpose devices such as smart phones,netbooks, laptops or other computing devices are used to deliver contentto subscribers. For example, a streaming video vendor may provide richmedia content to subscribers without requiring the subscribers toconsume bandwidth from their wireless network provider. In particular,streaming video vendor pays the wireless network owner to deliver thestreaming media content to the subscribers. Even if the subscribers havean account with the wireless network owner, the bandwidth required tostream the content is not counted against the allocated bandwidthassociated with the subscriber account. The video vendor is thusmotivated to stream content at a lower rate when the cost for access ishigh, and may provide higher rate, higher resolution video when thenetwork is not congested and the access price cost paid by the videovendor is low. Similarly content providers may send static pictureadvertisements when access costs are high, and stream videoadvertisements when access costs are low.

Various embodiments provide for content delivery or streaming at aguaranteed bit rate, a bit rate associated with a particular quality ofexperience (QoE) tier, a minimum bit rate, a best efforts bit rate andso on, where each of these delivery paradigms is associated with adetermined price that changes in accordance with network conditions andother parameters.

Sponsored content may be further subsidized by including advertisingwith the delivered content. For example, some embodiments contemplatereducing the price for access purchasers in exchange for the accesspurchasers presenting advertisements to their subscribers. Further pricereductions may be provided where sufficient demographic informationassociated with the subscribers is provided such that the advertisingmay be well targeted or highly relevant to the subscriber.

As an example, consider and add-on feature associated with asubscription-based sports network or other application content provider(ACP). For flat monthly fee, subscribers may access the ACP content viatheir home broadband connection, such as cable television, satellitetelevision, fiber to the curb and the like. For an additional monthlyfee paid to the ACP, subscribers may also access the ACP content via awireless network on their smart phones, tablet computers, laptop petersand the like. Importantly, a portion of the additional monthly fee paidto the ACP is used by the ACP to pay for access to the wireless networksuch that the monthly wireless network bandwidth allocation of thesubscriber is not consumed by viewing the ACP content.

The mobile operator or wireless network owner publishes pricing tariffsand the like based on network conditions and/or other factors asdescribed herein. The ACP purchases access instantaneously or in a “spotmarket” fashion to satisfy subscriber demands for ACP content. Invarious embodiments, ACP may purchase bulk access/bandwidth from themobile operator in anticipation of ACP subscriber demands.

In various embodiments, the ACP responds to changes in wireless accesstariff pricing by adapting one or more of the video rate or quality ofcontent, whether or not advertising is inserted into the content stream,how many advertisements are inserted within the content stream, whetheror not the content stream itself is delayed until the tariff drops belowa threshold level and so on. Various business modifications may be madeby those skilled in the art and informed by the teachings of the presentembodiments.

FIG. 5 depicts a high-level block diagram graphically representing anAccess Market Place (AMP) using congestion pricing to advertise accessnetwork tariffs, transact with Application Content Providers (ACPs) forwireless access to their subscribers for content delivery, delivercontent to the User Equipment (UE) of the subscribers, and properlycharge the ACP.

Specifically, FIG. 5 depicts a system 500 including network 510including a plurality of eNodeBs 511 serving wireless user equipment(UE) or user devices (UD) 502. The system 500 may be configuredsimilarly to the system 100 described above with respect to FIG. 1.

At a first step (step 1), a network congestion monitoring element 570obtains network congestion information and provides the networkcongestion information to an intelligent presence element 560.

In various embodiments, the network congestion monitoring element 570comprises an ALU 9900 Wireless Network Guardian (WNG), manufactured byAlcatel-Lucent of Murray Hill, N.J. The WNG provides cell levelcongestion information to support Analytics and real-time servicecontrol functions. The WNG is a network vendor independent source ofcongestion information that AMP uses to determine pricing for access. Invarious embodiments, network congestion information is derived directlyfrom the various network elements within the cell, the region includingthe cell and so on. Congestion information used to define access pricesand tariffs may be from the network congestion monitoring element 570,from various other network elements, from the management system or fromany combination thereof.

At a second step (step 2), the intelligent presence element 560calculates third-party access pricing for each cell and adds metadataassociated with the cells (e.g., RAT, UE state and the like), formulatesa pricing tariff or market offer, and propagates the offer toward amarketing platform, illustratively the Alcatel-Lucent Open API Platform(OAP). In various embodiments, the network congestion information iscombined metadata provided by an Alcatel-Lucent Intelligence Presence(InP) server. The metadata includes, illustratively, information that isrelevant to applications that may wish to purchase access, and myinclude UE state (battery charge, processor occupancy, etc.) and accesstechnology (e.g., GPRS, UMTS, LTE, etc.).

At a third step (step 3), the OAP exposes the formulated pricing tariffor market offer to application content providers (ACPs) and otherentities via, illustratively, an application programming interface(API). In various embodiments, the pricing and metadata is securelyexposed to the market place using RESTful APIs via the ALU Open APIPlatform (OAP).

At a fourth step (step 4), the ACP purchases wireless access accordingto the exposed or offered tariff. In various embodiments, an ACP entity590 such as a content server, session manager or other functionalelement utilizes the RESTful APIs published via the Open API Platform(OAP) to effect an automated wireless access purchase transaction inresponse to, illustratively, a subscriber request for content receivedby the ACP.

For example, assuming a particular ACP subscriber requests content fromthe ACP in a standard manner via the subscriber's UE 502, the ACPidentifies the requesting subscriber, uses the metadata to identify thespecific eNodeB servicing the subscriber, and generates an accesspurchase request according to the tariff or pricing structure associatedwith the identified subscriber eNodeB. Note that the metadata may besupplied by the UE, obtained from the network or dedicated locationservers, or other sources.

At a fifth step (step 5), the access purchase request is received fromthe ACP via the OAP and propagated toward a PCRF for proper chargingand, optionally, to control or constrain QoS level via, illustratively,policy modifications and the like.

In various embodiments, content delivered at peak/expensive access timesmay be quality constrained with respect to content delivered atoff-peak/inexpensive access times. For example, various ACPs react indifferent ways to changes in pricing, such as making access purchasedecisions by altering their streaming video rate from high resolution,to standard resolution and to low resolution in response to pricechanges. Different applications may set different price-level triggerpoints for resolution or other QoS changes. Different applications mayalso set different advertising insertion policies such adapting by usingvideo advertising, using static advertising, increasing or decreasingadvertising insertion rates and so on in response to changes in accesspricing.

These decisions may also take into account the relative value of theadvertisement to the ACP versus the cost of presenting the advertisementto subscriber. It may be cheaper to provide content without advertisingto a subscriber if the access cost of presenting the advertising to asubscriber exceeds the revenue associated with the advertising.

At a sixth step (step 6), the requested content is provided by the ACPto the user via the wireless network. In various embodiments, an ACPserver 590 streams requested content to a packet Gateway (PGW) 513associated with the wireless network 510. Optionally, advertisementsreceived from, illustratively, an advertising server 595 areperiodically inserted into the stream content. The PGW receiving thecontent at the edge of the wireless network identifies the packets assponsored application packets and identifies these packets as not to becounted against the bandwidth allocation associated with the subscriber.

At a seventh step (step 7), information is transmitted from the PGW 513to a charging (OCS) entity 580 where the volume counted by the PGW forthe various flows are rated for charging purposes so ACP and thesubscriber can be charged appropriately.

FIG. 6 graphically depicts exemplary application content providerpolicies for two different application content providers. Specifically,each of a first ACP 610A a second ACP 610B have established sixpricing-related trigger points, where each trigger point is associatedwith a respective quality and/or advertising policy associated withrequested content stream. That is, network access tariffs or pricelevels driven by network congestion levels and the like are in turn usedto define quality of experience (QoE) and/or quality of service (QoS)parameters associated with content streamed to a requesting user.

The six pricing-related trigger points and related policies for thefirst ACP 610A are shown below in Table 1, as follows:

TABLE 1 Price Video Advertising 0 HD video at high bitrate 3 VideoAdvertisements 1 HD video at 2-step lower bitrate 2 Video Advertisements2 HD video at 2-step lower bitrate 1 Video Advertisement 3 SD video athigh bitrate 2 Static Advertisements 4 SD video at 1 -step lower bitrate1 Static Advertisement 5 SD video at 2-step lower bitrate NoAdvertisements

The six pricing-related trigger points and related policies for thesecond ACP 610B are shown below in Table 2, as follows:

TABLE 2 Price Video Advertising 0 HD video at high bitrate 1 VideoAdvertisement 1 HD video at high bitrate 1 Video Advertisement 2 HDvideo at 1-step lower bitrate 1 Video Advertisement 3 HD video at 2-steplower bitrate 1 Video Advertisement 4 SD video at high bitrate 2 StaticAdvertisements 5 SD video No Advertisements

The various embodiments advantageously provide an opportunity forservice providers to increase revenue from application/content providerswhile incentivizing more efficient utilization of the networkinfrastructure. In particular, by shifting access costs to accesspurchasers having business relationships with network subscribers, thecost associated with subscriber behavior such as bandwidth consumptionmay be more properly allocated among the various subscribers as well asamong the various access purchasers.

FIG. 7 depicts a high-level block diagram of a general purpose computersuitable for use in performing the functions described herein withrespect to the various embodiments. In particular, the architecture andfunctionality discussed herein with respect to the general-purposecomputer is adapted for use in each of the various switching andcommunication elements or nodes discussed herein with respect to thevarious figures; such as the UDs 102, eNodeBs 111, SGWs 112, PGW53, MMEs114, PCRF 115, and management system 140. It will be appreciated thatsome of the functionality discussed herein with respect to describegeneral purpose computer may be implemented in various network elementsor nodes, and/or a network operations center (NOC) or network managementsystem (NMS) operative to configure and manage elements within thenetwork.

As depicted in FIG. 7, system 700 comprises a processor element 702(e.g., a CPU), a memory 704, e.g., random access memory (RAM) and/orread only memory (ROM), a packet processing module 705, and variousinput/output devices 706 (e.g., storage devices, including but notlimited to, a tape drive, a floppy drive, a hard disk drive or a compactdisk drive, a receiver, a transmitter, a speaker, a display, an outputport, and a user input device (such as a keyboard, a keypad, a mouse,and the like)).

It will be appreciated that computer 700 depicted in FIG. 7 provides ageneral architecture and functionality suitable for implementingfunctional elements described herein and/or portions of functionalelements described herein. Functions depicted and described herein maybe implemented in software and/or hardware, e.g., using a generalpurpose computer, one or more application specific integrated circuits(ASIC), and/or any other hardware equivalents.

It is contemplated that some of the steps discussed herein as softwaremethods may be implemented within hardware, for example, as circuitrythat cooperates with the processor to perform various method steps.Portions of the functions/elements described herein may be implementedas a computer program product wherein computer instructions, whenprocessed by a computer, adapt the operation of the computer such thatthe methods and/or techniques described herein are invoked or otherwiseprovided. Instructions for invoking the inventive methods may be storedin fixed or removable media, transmitted via a data stream in abroadcast or other signal bearing medium, transmitted via tangible mediaand/or stored within a memory within a computing device operatingaccording to the instructions.

While the foregoing is directed to various embodiments of the presentinvention, other and further embodiments of the invention may be devisedwithout departing from the basic scope thereof. As such, the appropriatescope of the invention is to be determined according to the claims,which follow.

What is claimed is:
 1. A method for vending network access, comprising:determining access prices for each of a plurality of network accessregions in response to at least one network operating condition; andoffering network region access in accordance with said determinedprices.
 2. The method of claim 1, wherein said network region comprisesa region serviced by one or more of an eNodeB, an eNodeB cell, a NodeB,a Node B cell, a BTS and a BTS Cell.
 3. The method of claim 1, whereinsaid network region comprises a region serviced by an eNodeB cell. 4.The method of claim 1, wherein said at least one network operatingcondition comprises a congestion level.
 5. The method of claim 1,wherein said at least one network operating condition comprises one ormore of a congestion level, a quality of service level, an accesstechnology and a target subscriber level of activity.
 6. The method ofclaim 1, wherein said access prices are adapted in response to anacceptance of advertising.
 7. The method of claim 1, wherein a firstprice tier for network region access is associated with a first qualityof service (QoS) level and a second price tier for network region accessis associated with a second QoS level.
 8. The method of claim 5, whereinthe first QoS level comprises a guaranteed bandwidth allocation.
 9. Themethod of claim 1, further comprising providing with said determinedprices metadata indicative of respective user equipment associated withsaid plurality of network access regions.
 10. The method of claim 9,further comprising: receiving an access purchase request indicative ofan acceptance of offered network services at said determined prices byan access purchase; adapting a Charging Rules Function to cause saidrequested access to be charged to said access purchaser.
 11. The methodof claim 10, further comprising adapting a Policy Rules Function toselect a quality of service (QoS) level for content provided via saidrequested network access.
 12. The method of claim 1, wherein saidnetwork region access is offered via an applications programminginterface (API).
 13. The method of claim 12, wherein said API is exposedto potential access purchasers via a web services gateway.
 14. Themethod of claim 12, wherein the web services gateway interacts with saidaccess purchasers to form an access marketplace providing updatednetwork access pricing for each of a plurality of eNodeBs or portionsthereof.
 15. The method of claim 1, further comprising providingrequested network access to an access purchaser in accordance with aquality of service (QoS) level.
 16. An apparatus for vending networkaccess, the apparatus comprising: a processor configured for:determining access prices for each of a plurality of network accessregions in response to at least one network operating condition; andoffering network region access in accordance with said determinedprices.
 17. The apparatus of claim 16, wherein said network regioncomprises one or more of an eNodeB, an eNodeB cell, a NodeB, a Node Bcell, a BTS and a BTS Cell.
 18. The apparatus of claim 16, wherein saidat least one network operating condition comprises one or more of acongestion level, a quality of service level, an access technology and atarget subscriber level of activity.
 19. A computer readable mediumincluding software instructions which, when executed by a processer,perform a method, comprising: determining access prices for each of aplurality of network access regions in response to at least one networkoperating condition; and offering network region access in accordancewith said determined prices.
 20. A computer program product, wherein acomputer is operative to process software instructions which adapt theoperation of the computer such that computer performs a method,comprising: determining access prices for each of a plurality of networkaccess regions in response to at least one network operating condition;and offering network region access in accordance with said determinedprices.